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THE  PC  DUGOUT  MICRO-MAINFRAME  INTEGRATION 
SYSTEM:  PAX  IMPLEMENTATION 


1  INTRODUCTION 


Background 

This  report  describes  the  research,  development,  and  implementation  of  PC  Dugout,  one  of  the 
applications  on  the  Programming,  Administration,  and  Execution  (PAX)  mainframe  computer  system.  PC 
Dugout  was  designed  to  support  the  Army’s  goal  of  shifting  selected  processing  tasks  from  tire  PAX 
mainframe  to  users’  personal  computers  (PCs).  This  goal  posed  a  number  of  technical  and  operational 
challenges  described  in  Chapter's  2  through  5. 

PAX  is  a  mainframe-based  timesharing  system  developed  by  the  U.S.  Army  Corps  of  Engineers 
(USACE)  to  support  the  Army’s  portion  of  the  Military  Construction,  Army  (MCA)  program.  Through 
the  PAX  system  menu  a  number  of  applications  are  available  to  users,  including  the  DD  Form  1391 
Processor,  the  Automated  Multi-Year  Plan  Application  Subsystem  (MYPLAN).  the  Economic  Analysis 
Package  (ECONPAC),  and  the  Construction  Appropriation,  Programming,  Control,  Execution  System 
(CAPCES).  These  systems  assist  with  the  identification,  planning,  management,  and  approval  of  Army 
construction  projects;  they  guide,  control,  and  facilitate  the  review  process  throughout  the  chain  of 
command. 

The  PAX  applications  arc  characterized  by  centralized,  rather  than  distributed,  databases,  The 
central,  shared  databases  provide  geographically  distributed  users  access  to  current,  official  Army 
documents  and  data  such  as  DD  Form  1391s  and  economic  analyses.  PAX  applications  also  provide  users 
standardizitd  operating  procedures,  extensive  data  validation  capabilities,  and  help  in  reducing  errors. 

With  the  current  widespread  availability  of  PCs  and  increased  sophistication  of  PC  software,  the 
Corps  of  Engineeis  wants  to  more  fully  exploit  users’  PCs  while  lowering  PAX  computing  costs.  PCs 
offer  a  number  of  advantages  over  mainframe  timesharing  systems,  including: 

•  lower  operating  costs 

•  quicker  response  to  u.sers 

•  improved  user  interfaces. 

The  data  used  by  any  one  system  user  is  composed  of  information  entered  into  the  system  by  many 
system  users  located  all  over  the  world  and  of  every  echelon  of  the  Amriy  (and  other  agencies).  PC 
applications  lack  the  capacity  to  support  such  an  operation. 

PAX  applications  cannot  be  moved  entirely  to  PCs  because  that  would  require  distributed  databases, 
and  local  PCs  cannot  be  dedicated  to  support  distributed  data.  In  addition,  the  applications  themselves 
are  not  designed  to  use  distributed  database  architecture.  One  of  the  primary  purposes  uf  PAX  is  to  make 
available  to  system  users,  up-to-date  information  about  the  programming  and  budgeting  of  military 
construction  sorted  at  the  installation,  MACOM,  DA,  and  other  levels.  This  is  not  achieved  with 
distributed  databases. 


5 


Objective 


The  system  had  to  support  worldwide  distribution  of  applications  in  a  manner  transparent  to  users 
of  differing  levels  of  computer  proficiency,  and  had  to  reliably  assure  that  all  users  in  the  field  are  using 
the  latest  versions  of  the  multiuser  applications. 


Approach 

The  best  solution  was  to  take  advantage  of  the  benefits  of  both  mainframe  and  personal  computers 
by  linking  preprocessing  on  PCs  with  central  mainframe  processing.  PAX  applications  would 
then  have  software  residing  both  on  users’  PCs  and  on  the  PAX  mainframe.  With  this  approach  in  mind, 
the  next  step  was  to  establish  criteria  for  the  distribution  of  PAX/PC  applications  and  related  functions. 
Chapter  2  describes  the  specific  requirements  tlmt  were  developed  for  PC  Dugout. 


Mode  of  Technology  Transfer 


PC  Dugout  is  available  for  general  use  as  a  function  of  the  PAX  system.  Users  may  obtain  a  PAX 
logon  identification  (ID  or  PAXID)  by  contacting  Mr.  Michael  Rice  at  Headquarters,  U.S.  Army  Corps 
of  Engineers  (HQUSACE),  Directorate  of  Military  Programs,  Washington,  DC,  (202)  272-0577.  PC 
Dugout  is  available  as  a  subsystem  to  all  PAX  users.  Once  logged  in  with  a  PAXID  a  user  is 
automatically  registered  for  the  PC  Dugout  subsystem.  There  is  no  software  for  the  user  to  install;  PC 
Dugout  is  installed  automatically  on  the  user’s  PC  once  the  user  requests  the  PC  Dugout  subsystem. 
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2  CRITERIA  FOR  DEVELOPING  PC  DUGOUT 


The  distribution  of  PAX/PC  applications  must  meet  certain  criteria  in  order  to  fulfill  th*.  Army’s 
requirements  for  efficiency,  reliability,  and  ease  of  use.  The  PC  Dugout  operating  environment  is 
characterized  by: 

•  hundreds  of  users,  distributed  worldwide 

•  large,  centrally  controlled,  shared  mainframe  databases 

•  continually  changing  mainframe  software  and  application  requirements 

•  many  applications,  operating  independently,  that  must  be  supported. 

The  following  major  requirements  for  PC  Dugout  wei '  developed  after  a  thorough  analysis  of  the 
PAX  environment  and  user  needs. 


Reliable  Distribution  of  PAX/PC  Applications 

A  reliable  method  had  to  be  found  to  distribute  PC  software  to  PAX  users.  The  software  developed 
for  this  task  must  be  robust — impervious  to  transmission  or  user  errors — and  should  require  minimum 
maintenance. 


Ease  of  Use 

Many  users  around  the  world  access  the  PAX  system  dally.  Most  of  these  users  are  not  computer- 
oriented  and  user  turnover  is  high.  Thus,  ease  of  use  was  a  fundamental  necessity  for  any  PAX 
application.  PC  Dugout  procedures  must  be  simple  and  easy  to  learn  without  a  training  course.  PC 
Dugout  should  also  be  self-installing  and  have  an  on-line  help  facility. 


Productive  Use  of  PCs 

PCs  are  now  available  to  virtually  all  PAX  users.  It  is  highly  desirable  to  take  full  advantage  of 
this  installed  equipment.  Along  with  distributing  PAX/PC  applications,  PC  Dugout  should  be  used  to 
improve  communications  between  PAX  users,  to  help  users  operate  their  PCs  more  effectively,  and  to 
promote  the  sharing  of  various  PC  techniques  and  knowledge  among  PAX  users. 


Cost  Efficiency 

PC  Dugout  must  be  cost  effective  and  result  in  lower  overall  PAX  processing,  personnel,  and 
maintenance  costs.  The  software  must  be  efficient  and  minimize  processing  and  software  fees  by  at  least 
20  to  25  percent  of  current  operating  cost.  PAX/PC  applications  have  a  potential  to  reduce  PAX  system 
cost  from  15  to  67  percent  or  more  as  compared  to  mainframe  processes.  Savings  to  the  government  from 
these  procedures  could  amount  to  $1  million  to  $4  million  per  year  as  PAX  system  use  grows.  One 
application,  PC-PAXMAIL  is  expected  to  save  users  between  $300,000  to  $500,000  in  its  first  12  months 
of  use.  It  will  be  maintained  by  use  of  PC  Dugout. 
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Multiple  Application  Tracking 


PC  Dugout  will  distribute  multiple  independent  PC  applications  maintained  by  sponsors  who  issue 
updates  at  various  times.  Users,  however,  win  .  nly  select  PC  applications  pertaining  to  their  jobs.  PC 
Dugout  must  be  able  to  track  which  applicatioi.s  are  installed  on  each  user’s  PC  and  who  should  be 
notified  when  an  application  is  updated. 


Identification  of  Users 

The  system  must  be  able  to  identify  and  track  each  user  and  machine  since  the  system  will  need  to 
keep  track  of  who  has  particular  applications,  and  notify  users  when  updates  arc  required. 


Distribution  of  Updates 

PAX  mainframe  applications  are  often  improved  or  modified  due  to  changes  in  requirements  and 
operating  procedures.  PC  Dugout  must  distribute  and  install  the  updates  to  these  mainframe  changes  as 
well  as  the  applications  themselves. 


Verification  of  Proper  Application  Installation 

PC  Dugout  must  be  able  to  verify  that  applications  or  updates  have  been  successfully  installed  on 
a  I  scr’s  PC.  To  accomplish  this,  PC  Dugout  needs  an  automated  checking  mechanism  that  will,  without 
user  intervention,  determine  whether  an  application  has  been  installed  properly  or  not.  A  redundant 
checking  mechanism  was  also  required  foi  periodically  checking  PC  application  files  to  insure  that  nothing 
has  been  destroyed  or  altered.  In  addition,  the  status  of  each  application  for  each  person  should  be 
tracked.  This  will  assist  in  distributing  revisions  and  identifying  users  with  problems. 


Security  Features 

The  integrity  of  PAX  applications  and  data  must  be  maintained.  PAX  applications  must  have 
safeguards  against  the  use  of  obsolete  programs  and  data  files.  In  addition,  PC  Dugout  procedures  need 
to  address  the  threat  of  computer  viruses. 


Management  of  Users  and  Applications 

The  management  of  users  and  applications  is  critical  in  a  distributed  environment.  The  presence 
on  the  system  of  hundreds  of  users  located  throughout  the  world  adds  to  the  complexity  of  maintaining 
data  and  system  integrity.  PC  Dugout  needs  a  coordinator  responsible  for  PC  Dugout  maintenance  and 
coordination  with  system  developers.  The  coordinator  must  also  review  and  test  all  software  and 
newsletters  before  their  release.  Applications  must  be  tested  for  computer  viruses  and  checked  to 
see  that  all  required  user  documentation  is  completed  before  release. 
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Reports  should  be  available  to  both  the  PC  Dugout  coordinator  and  system  developers  that  list  all 
users  for  a  particular  application,  and  whether  or  not  those  users  have  successfully  installed  current 
software  versions. 


Coordination  With  Software  Developers 

PC  Dugout  must  be  easy  for  system  developers  to  work  with.  There  must  be  coordination  between 
system  developers  and  the  PC  Dugout  coordinator  for  the  timing  and  notification  of  software  releases. 
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3  GENERAL  PC  DUGOUT  FEATURES 


After  the  requirements  for  PC  Dugout  were  specified,  the  basic  features  of  the  application  were 
constructed.  The  design  for  PC  Dugout  includes  the  basic  capabilities  described  below. 


PC  Registration  Function 

The  first  time  a  particular  PC  is  used  to  access  PC  Dugout,  a  registration  process  is  initiated. 
Certain  PC  Dugout  programs  and  files  are  automatically  installed  on  the  user’s  PC.  From  then  on,  PC 
Dugout  maintains  itself  on  the  PC,  automatically  checking  and  repairing  files  each  time  the  user  enters 
the  program.  During  the  registration  process  users  are  asked  to  provide  their  name  and  address 
information;  a  unique  PC-identification  number  is  then  issued  to  enable  PC  Dugout  to  traek  the  user’s 
applieations. 


Newsletter  Function 

This  feature  provides  users  information  pertaining  to  PC  Dugout,  PAX/PC  applications,  and  items 
of  general  interest  to  PC  users.  For  example,  newsletter  artieles  may  contain  information  on  PAX/PC 
system  enhancements  and  who  to  contact  for  assistance.  Newsletters  may  also  contain  ideas  and 
techniques  that  will  help  PAX  users  employ  their  PCs  more  effeetively.  Users  can  have  a  selected 
newsletter  printed  on-line  immediately,  or  they  can  have  a  file  containing  the  newsletter  created  on  their 
PC. 


Utilities  Function 

This  function  provides  access  to  a  library  of  PAX-related  PC  utilities.  These  fairly  simple  stand¬ 
alone  utilities  are  a  eombination  of  text  and  PC  programs  that  can  help  users  with  specific  operations. 
For  example,  users  can  download  utilities  to  pack  (compress)  and  unpack  files,  sort  directories,  or 
automate  log-on  procedures.  Descriptions  of  these  programs  and  the  programs  themselves  can  be  selected 
from  a  menu  and  copied  automatic^ly  to  a  user’s  PC. 


PAX/PC  Application  Function 

The  Application  function  is  designed  to  distribute  and  maintain  PC-based  PAX  applications  that 
work  with  PAX  mainframe  applications.  This  function  allows  users  to  register  for  PAX/PC  applications, 
and  download  and  verify  those  applications.  When  the  user  has  selected  the  desired  PAX  applications  this 
function  will  automatically  keep  those  applications  updated.  When  entering  PC  Dugout,  users  will  be 
notified  if  their  applications  are  outdated. 


Submit  Function 

The  Submit  capability  enables  a  user  to  contribute  PC  software  utilities  or  newsletter  articles  to  the 
entire  PAX  user  community  via  PC  Dugout.  This  feature  also  enables  users  to  send  comments  to  the  PC 
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Dugout  coordinator.  System  developers  submit  PAX/PC  applications  to  the  co^-roinator  via  this  function. 
The  coordinator  reviews  and  tests  the  software  before  it  is  released  through  PC  Dugout. 


Help  Feature 

Users  need  not  remember  procedures  or  continually  refer  to  Lheir  user  manuals  because  PC  Dugout 
provides  on-line  documentation.  A  user  may  enter  “HELP"  in  response  to  any  prompt,  and  the  system 
will  respond  with  a  description  of  the  appropriate  responses.  This  feature  is  designed  to  ensure  the 
system’s  ease  of  use  and  minimize  user  support  requirements. 


Menu  Interfaces  and  Automated  Fite  Transfers 

To  further  insure  PC  Dugout’s  ease  of  use  and  reduce  opportunities  for  user  error,  menu  interfaces 
and  fully  automated  file  transfers  were  implemented. 

PC  Dugout’s  user  interface  consists  entirely  of  menus.  Users  simply  select  the  menu  command  they 
wish  to  execute.  This  takes  them  to  another  level  of  menus,  where  they  select  the  desired  action  or  item. 
Users  do  not  have  to  remember  any  commands  or  language  syntax.  In  some  cases  users  are  asked  to 
answer  a  few  simple,  nontechnical  prompts.  To  download  or  upload  files,  a  user  simply  selects  a 
command  from  a  menu  and  answers  one  or  two  prompts.  The  PC  Dugout  menu  structure  is  illustrated 
in  Figure  1. 


PC  Dugout  Coordinator 

The  PC  Dugout  coordinator  (DC)  manages  the  Dugout  system.  The  coordinator  has  access  to  an 
expanded  PC  Dugout  menu,  which  contains  commands  for  executing  administrative  tasks  such  as  releasing 
and  deleting  PAX/PC  applications. 

To  protect  users  and  data,  all  submissions  (i.e.,  PAX/PC  applications,  newsletters,  and  utilities)  are 
placed  in  a  “pending”  mode.  The  coordinator  reviews  all  submissions  before  releasing  them  to  users. 
Submissions  are  checked  for  viruses  and  integrity.  The  coordinator  works  closely  with  system  developers 
to  plan  PC  software  release  dates. 

The  coordinator  also  has  access  to  a  number  of  PC  Dugout  management  reports  that  help  provide 
insight  into  what  users  are  doing.  Data  stored  in  the  Pc  Dugout  database  can  be  presented  in  prepro¬ 
grammed  reports  that  include: 

•  lists  of  all  users  registered  for  a  particular  application,  including  PAXID,  name,  address 
information,  phone  number,  and  current  application  status 

•  mailing  labels  addressed  to  users  registered  for  a  particular  application 

•  lists  of  users  and  whether  or  not  their  applications  have  been  updated. 
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4  IMPLEMENTATION  TOOLS 


This  chapter  describes  the  requirements  for  the  software  tools  used  to  implement  PC  Dugout  and 
explains  why  certain  software  products  were  used.  The  PAX  environment  is  also  briefly  reviewed. 


PAX  Mainframe  Environment 

The  PAX  applications  operate  in  an  IBM  VM/CMS*  environment.  Users  access  the  mainframe 
through  an  asynchronous  dial-up  network  at  data  transmission  speeds  ranging  from  300  to  9600  baud,  with 
1200  baud  being  most  common.  PC  Dugout  users  are  not  permitted  to  directly  issue  VM/CMS 
commands — all  PAX  functions  are  made  available  to  users  through  a  main  PAX  menu  presented  at  login. 
Each  PAXID  has  a  customized  menu  that  includes  only  the  applications  and  functions  authorized  for  the 
ID.  PC  Dugout  has  been  added  to  user’s  menus,  allowing  access  to  the  PC  Dugout  application. 


Selection  of  a  Database  Management  System 

PC  Dugout  operations  require  that  multiple  users  be  able  to  access  and  update  the  central  mainframe 
database  simultaneously.  However,  simultaneous  read  and  write  access  to  files  is  not  supported  directly 
by  the  VM/CMS  operating  system.  CMS  was  designed  as  a  single-user  operating  system,  so  its  file  access 
mechanisms  do  not  support  shared  access  to  files.  Database  management  system  (DBMS)  vendors  have 
developed  various  approaches  to  solve  the  shared  access  problem.  The  database  management  systems 
Focus  and  Structured  Query  Language/Data  System  (SQLyDS)  successfully  circumvent  this  restriction  in 
the  PAX  VM/CMS  operating  environment.  Focus  is  the  DBMS  for  most  PAX  applications,  but  its 
operating  overhead  would  be  excessive  for  PC  Dugout.  Therefore,  SQL/DS  was  chosen  for  the 
implementation  of  PC  Dugout.  SQL/DS  provides  a  relational  database  that  can  be  used  effectively  by  PC 
Dugout,  and  it  provides  significant  ope'^ating  efficiencies. 

The  design  of  SQL/DS  places  great  emphasis  on  efficient  data  retrieval  for  multiple  users.  Retrieval 
techniques  used  include  use  of  the  most  efficient  access  path  to  satisfy  a  request  and  extensive  use  of 
memory  buffers.  Because  of  SQL/DS  buffering,  some  of  PC  Dugout’s  smaller  tables  may  reside 
completely  in  random  access  memory  (RAM).  Retrieving  data  from  such  tables  does  not  require  physical 
disk  accesses,  and  this  results  in  dramatic  improvements  in  both  operating  costs  and  system  response  tin 


Mainframe  Implementation  Language 

Restmetured  Extended  Executor  (REXX)  was  chosen  as  the  implementation  language  for  developing 
mainframe  PC  Dugout  because  of  its  flexibility  and  ease  of  use.  REXX  is  an  interpreted  language,  which 
is  ideal  for  development  and  prototyping  since  it  requires  no  compilation  step.  Additionally,  there  is  a 
REXX/SQL  interface  available  that  permits  direct  access  to  SQL  data  from  REXX  procedures.  REXX 
was  chosen  over  EXEC2  because  it  is  less  costly  to  use  than  EXEC2,  and  provides  a  structured  language 
that  is  easier  to  code.  It  is  also  targeted  by  IBM  Coip.  to  replace  that  company’s  EXEC  and  EXEC2 
language  processors,  and  is  one  of  the  products  included  under  IBM’s  Systems  Application  Architecture 


'VM/CMS  i.s  Virtual  Machine/Convcrsational  Monitor  System. 
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(SAA).  This  is  important  because  SAA  is  IBM’s  approach  to  developing  applications  that  will  be  able 
to  run  on  any  IBM  computer  in  the  future. 


PC  Implementation  Language 

Some  PC  Dugout  functions  will  be  implemented  on  the  PC  and  invoked  from  the  mainframe.  The 
C  language  was  chosen  for  the  development  of  PC  Dugout  programs  because  it  is  easy  to  code  and 
maintain,  and  there  are  several  suitable  compilers  available  for  the  IBM  PC.  Programs  written  for  PC 
Dugout  can  also  be  ported  to  other  PC  architectures  if  they  are  written  in  C. 

Microsoft’s  QuickC  compiler  was  chosen  for  development  because  it  best  fit  the  requirements  of 
PC  Dugout  and  features  an  interactive  development  environment.  QuickC  also  generates  small  compiled 
modules  that  can  be  easily  distributed  from  the  mainframe.  The  programs  can  be  recompiled  later  with 
the  Microsoft  Optimizing  C  compiler  if  further  reductions  in  module  size  are  required.  QuickC  does  not 
require  a  mn-time  module  so  there  are  no  fees  or  licensing  restrictions.  The  compiled  code  executes 
quickly  so  resource-intensive  PC  Dugout  programs  do  not  create  long  delays. 


Communications  Package  and  File  Transfer  Protocol  Requirements 

The  high  degree  of  user  friendliness  and  control  needed  in  the  PAX  environment  requires  the 
automation  of  all  PC  Dugout  operations  on  the  PC.  PC  Dugout  must  be  able  to  determine  the  status  of 
a  user’s  PC  application  and  replace  outdated  files  with  minimal  user  interaction.  Also,  future 
enhancements  may  require  even  more  automation,  such  as  the  updating  of  applications  overnight  without 
any  intervention  by  the  user. 

Communications  Package  Requirements 

Communications  software  requirements  can  be  best  met  by  a  package  that  provides  the  following 
minimum  capabilities; 

•  the  execution  of  DOS  (disk  operating  system)  commands  and  PC  programs  under  control  of  the 
mainframe  application 

•  two-way  file  transfers  initiated  by  the  mainframe. 

Tym/COMM  (BT  Tymnet)  and  VistaCOM  (CDC),  both  supported  in  PAX,  satisfy  these 
requirements.  ProComm,  although  widely  used  by  the  Army,  is  not  appropriate  for  PC  Dugout  because 
it  does  not  support  the  execution  of  DOS  commands  or  file  transfers  under  mainframe  control.  The 
Appendix  reprints  the  findings  of  a  study  to  determine  which  communications  protocols  and  software 
packages  should  be  supported  by  PC  Dugout. 

Tym/COMM  and  VistaCOM  are  currently  used  by  PC  Dugout  so  users  will  have  a  choice  of 
communications  packages  and  the  Government  is  not  the  captive  of  a  single  vendor  source. 

The  PC  Dugout  communications  functions  were  implemented  as  a  master-slave  relationship 
controlled  by  the  mainframe.  This  permitted  the  use  of  off-the-shelf  communications  programs  and 
simplified  the  communications  aspect  of  PC  Dugout.  In  the  future,  extensions  to  PC  Dugout  may  be 
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added  to  support  a  peer-to-peer  communications  interface  in  addition  to  the  existing  master-slave 
relationship.  A  peer-to-peer  interface  would  facilitate  offloading  more  functions  to  the  PC.  However, 
provisions  have  been  added  for  other  communications  packages  to  access  PC  Dugout. 

File  Transfer  Protocol  Requirements 

The  transfer  of  files  by  PC  Dugout  from  one  computer  to  another  requires  the  cooperation  of  both 
the  sending  and  the  receiving  computers.  The  set  of  rules  governing  the  file  transfer  is  called  a  protocol, 
and  the  program  that  implements  these  rules  is  called  a  driver.  Most  PC  communications  packages  have 
drivers  that  support  several  different  protocols. 

To  be  viable  in  the  PC  Dugout  environment,  file  transfer  protocols  must  have  the  following  features: 

•  operation  in  the  PAX  environment  ('EM  VM/CMS  and  Tymnet) 

•  low-cost  file  transfers 

•  the  ability  to  transfer  both  text  and  binary  files 

•  the  ability  to  transfer  files  without  modification 

•  a  corrective  file  transfer  mechanism 

•  mainframe  file  compatibility  with  other  protocol  drivers. 

The  following  subsections  describe  these  criteria  in  more  detail. 

Operation  in  the  PAX  Environment.  The  protocols  available  for  PC  Dugout  operations  are  limited 
to  those  for  which  IBM  VM/CMS  drivers  are  available.  If  there  is  no  program  available  for  the 
mainframe  that  follows  the  protocol  conventions,  the  protocol  cannot  be  used.  In  addition,  the  drivers 
must  be  able  to  use  the  Tymnet  communications  networic.  Drivers  currently  available  within  the  PAX 
environment  are  COPYPC,  Kermit,  Vista,  and  XMODEM. 

Low  Cost  File  Transfers.  As  many  as  12  separate  PAX/PC  applications,  each  containing  many  files, 
will  be  distributed  and  updated  through  PC  Dugout.  The  applications  and  updates  will  be  downloaded 
to  many  PAX  users  worldwide.  Thus,  it  is  imperative  for  any  driver  used  in  PC  Dugout  to  provide 
relatively  low-cost  file  transfers. 

File  Transfer  in  Both  Text  and  Binary  Formats.  File  transfer  protocols  used  by  PC  Dugout  must 
be  able  to  transfer  both  text  and  binary  files  because  PC  Dugout  requires  both  types  of  files  to  operate. 
Text  files  contain  alphanumeric  information  in  a  form  suitable  for  reading.  The  characters  in  these  files 
are  translated  between  ASCII  and  EBCDIC'  so  they  can  be  used  either  on  the  PC  or  the  mainframe. 
Binary  files  are  typically  computer  program  files,  intended  for  use  only  on  the  PC.  Archive  files  are 
special  cases  of  binary  files  in  which  one  or  more  files  (either  text  or  binary)  are  compressed  and  collected 
in  a  single  file.  Most  PC  Dugout  application  files  are  compressed  into  archive  files  for  distribution:  they 
are  unarchived  on  the  user’s  PC  automatically.  This  operation  saves  disk  storage  space  in  PC  Dugout  and 
reduces  the  time  and  connect  charges  associated  with  file  transfers. 

File  Transfers  Without  Modification.  PC  Dugout  checks  the  validity  of  installed  PC  applications 
by  calculating  a  cyclical  redundancy  check  (CRC)  value  for  each  application  file  on  the  PC  and  comparing 
it  with  the  proper  CRC  value  downloaded  from  the  mainframe.  If  the  CRC  values  do  not  match,  a  correct 


'ascii  is  American  Standard  Code  for  Information  Exchange;  EBCDIC  is  Extended  Binary-Coded  Decimal  Interchange  Code. 
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version  of  the  application  file  is  downloaded  to  the  PC.  CRC  computation  requires  PC  Dugout  to  transfer 
an  exact  image  of  the  file. 

..t  all  file  transfer  protocols  can  accommodate  this  directly.  XMODEM,  for  example,  does  not. 
All  files  transferred  by  XMODEM  are  sent  in  full  128-character  blocks.  Thus,  a  file  originally  20 
characters  long  will  end  up  128  characters  long  after  it  is  transferred.  It  is  possible  for  PC  Dugout  to 
avoid  this  problem  if  all  application  files  are  archived  before  transmission  and  unpacked  later  on  the  user’s 
PC.  TThe  archive  is  not  affected  by  the  extra  characters,  and  when  the  application  files  are  unpacked,  they 
will  retain  their  original  size  pm  CRC  values. 

Corrective  File  Transfer.  A  corrective  file  transfer  capability  can  detect  and  correct  tiansmission 
errors  such  as  those  due  to  line  noise.  This  feature  is  required  for  protocols  used  with  PC  Dugout  to 
provide  an  acceptable  standard  of  reliability  for  file  transfers. 

Mainframe  File  Format  Compatibility.  Any  binary  PC  file  moved  to  the  mainframe  with  one 
protocol  must  be  usable  by  all  other  protocol  drivers.  If  a  file  is  uploaded  to  the  mainframe  using 
XMODEM,  for  example,  it  should  be  able  to  be  successfully  downloaded  to  a  PC  with  COPYPC.  The 
PAX  XMODEM  and  COPYPC  drivers  use  compatible  mainframe  file  formats.  An  option  has  been  added 
to  the  Vista  driver  to  use  files  compatible  with  COPYPC  and  XMODEM. 

File  Transfer  Protocols  Used  With  PC  Dugout 

Tym/COMM  using  COPYPC  is  currently  used  by  PC  Dugout  and  meets  all  file  transfer 
requirements.  VistaCOM  has  been  implemented  using  XMODEM,  which  can  meet  PC  Dugout’s  protocol 
requirements  as  well.  Vista,  a  protocol  designed  for  use  with  VistaCOM,  will  not  be  used  in  PC  Dugout 
since  the  number  of  transfer  charge  units  required  by  the  VistaCOM  driver  to  send  or  receive  a  file  is 
much  higher  than  either  XMODEM  or  COPYPC.  KERMIT  cannot  be  used  because  it  is  expensive  to  run 
and  its  protocol  overhcf  i  increases  connect  time  considerably. 

Mainframe  PC  Dugout  has  been  designed  in  a  modular  fashion  so  all  file  transfers  are  performed 
by  a  single,  iow-level  routine.  This  routine  identifies  the  communications  package  currently  in  use  and 
handles  all  details  of  the  file  transfer  invisibly  to  the  calling  routines.  This  design  structure  is  important 
because  it  isolates  PC  Dugout  operations  from  the  specific  communications  package  being  used.  The 
modular  structure  will  make  it  easier  to  integrate  additional  communications  packages  with  PC  Dugout 
in  the  future. 
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5  DUGOUT  DESIGN 


The  ma’n  purpose  of  PC  Dugout  is  the  distribution  and  control  of  PAX/PC  applications.  Designing 
the  portion  of  PC  Dugout  that  accomplishes  this  presented  the  greatest  technical  challenges.  Tliis  section 
describes  in  detail  PC  Dugout’s  primary  design  features,  which  include: 

•  how  PC  Dugout’s  mainframe  and  PC  programs  woric  together 

•  how  PC  Dugout  keeps  track  of  users 

•  how  applications  are  maintained  on  the  PC. 


PC  Dugout  Mainframe  and  PC  Programs 

PC  Dugout  functions  are  divided  between  the  PC  and  mainframe  based  on  the  strengths  of  each 
environment.  The  primary  interaction  between  the  PC  and  mainframe  consists  of  the  mainframe  issuing 
commands  and  controlling  the  transfer  of  files.  A  central  master  database,  which  is  used  for  control  and 
disUibution  functions,  is  implemented  on  PAX.  This  cennal  database  is  used  to  track  users,  applications, 
and  application  status  information.  It  also  forms  the  basis  for  administrative  reports  and  user  mailing  lists. 

Other  functions  are  supported  on  the  PC,  and  are  invoked  by  the  mainfiame  through  the 
Tym/COMM  communications  package.  The  PC  supports  functions  that  run  best  on  the  PC,  such  as  data- 
editing  routines,  testing  the  status  of  applications  installed  on  the  PC,  and  generating  status  reports  used 
to  update  the  central  database.  The  results  of  PC  commands  are  placed  in  files  and  transferred  to  the 
mainframe,  where  they  are  interpreted. 

Some  of  Dugout’s  PC  functions  can  also  be  run  in  a  stand-alone  fashion,  without  a  connection  to 
PAX.  When  stand-alone  operations  affect  data  stored  in  the  mainframe  database,  the  changes  are  recorded 
on  the  PC  and  transmitted  to  the  mainframe  the  next  time  PAX/PC  Dugout  is  accessed.  An  overall 
diagram  of  PC  Dugout  components  is  shown  in  Figure  2. 


PC  Dugout  Registration 

Users  gain  access  to  PAX  with  PAXIDs,  which  are  used  for  user  control  and  billing  purposes. 
Through  a  menu  system,  each  PAXID  is  allowed  access  to  a  group  of  applications  within  PAX.  PAXIDs 
may  be  shared  by  several  people  in  an  office  or  a  building.  Some  users  may  have  several  PAXIDs,  for 
development  or  other  purposes.  Similarly,  some  users  may  share  PCs  while  others  have  access  to  multiple 
PCs.  Network  environments  are  common  in  larger  offices.  Since  there  is  not  a  one-to-one  correlation  in 
the  number  of  PAX  users,  PAXIDs,  and  PCs,  user  information  and  PAXIDs  do  not  provide  all  information 
necessary  to  track  PC  applications  installed  by  PC  Dugout.  Instead,  PC  Dugout  tracks  the  registered  PCs 
because  the  applications  are  linked  to  specific  PCs. 

When  a  user  selects  the  PC  Dugout  option  from  the  PAX  menu  for  the  first  time,  the  user  is 
required  to  register  his  or  her  PC  before  further  access  is  permitted.  When  a  PC  is  registered  in  PC 
Dugout,  the  user’s  name,  address,  and  PAXID  are  entered  in  the  SQL  database.  A  unique  PC 
identification  number  is  generated  and  assigned  by  PC  Dugout,  and  files  are  installed  on  the  machine. 
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Figure  2.  PC  Dugout  components. 


The  files  installed  include: 

•  an  identification  file  containing  the  PC  Dugout  identification  number  (PCDID),  user  name  and 
address,  and  installed  application  information 

•  an  index  of  PC  Dugout  programs  with  CRC  values  of  the  correct  files  so  the  validity  of  PC 
Dugout  PC  programs  can  be  checked 

•  PC  Dugout  PC  programs  for  stand-alone  operation  and  for  use  by  PAX/PC  Dugout  (including 
programs  to  check  the  status  of  an  application  for  the  mainframe,  edit  address  information,  and  create  and 
use  archived  files). 

A  directory  is  created  to  hold  these  files  and  provide  a  uniform  filing  environment  for  PC  Dugout 
operations. 

When  a  registered  PC  is  used  to  access  PC  Dugout,  the  identification  file  is  copied  to  the  mainframe 
to  identify  Lhe  PC  in  use  and  update  the  mainframe  databas"  with  any  new  address  or  application 
infonnation.  The  mainframe  then  initiates  a  check  of  the  PC  Dugout  programs  to  ensure  that  they  are  all 
current.  If  any  files  are  missing  or  require  revision,  the  latest  version  of  the  PC  Dugout  program  is  moved 
to  the  PC.  After  the  PC  Dugout  application  itself  has  been  verified,  the  user’s  identification  file  is 
examined  to  determine  the  current  status  of  installed  applications,  user  address,  and  items  requiring  the 
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user’s  attention  within  PC  Dugout.  Information  is  extracted  from  the  SQL  database  and  checked  to  see 
if  there  have  been  updates  to  the  mainframe  version  of  each  application  since  the  current  user  last  checked. 
The  user  is  then  informed  of  any  applications  that  require  updates. 

This  approach  prevents  applications  from  being  installed  more  than  once  on  each  PC  even  if  the  PC 
is  shared.  Additionily,  if  a  user  has  several  PCs,  each  PC  can  be  tailored  individually  to  match  the 
operations  of  the  user.  A  particular  application  need  not  be  installed  on  each  machine.  For  network 
environments,  the  network  administrator  will  be  responsible  for  registering  the  ser/t  «•  and  ensuring  that 
the  network  has  the  most  recent  version  of  each  application  installed. 

The  Machine  Identification  Table 

Each  registered  PC  is  assign  ;d  a  record  (row)  in  the  Machine  Identification  Table  in  the  SQL/DS 
database.  The  items  (columns)  recorded  are  described  in  Table  1.  The  entire  record  is  devoted  to  user 
information.  It  contains  no  applications  or  application  status  columns. 


Application  Identification 

PC  Dugout  distributes  and  maintains  multiple,  discrete  PC  applications.  These  applications  consist 
of  files  that  are  downloaded  to  users'  PCs.  To  distribute  an  application  through  PC  Dugout,  system 
developers  must  submit  all  program  files,  user  documentation,  and  data  files  required  by  the  application. 
System  developers  must  also  submit  the  following  application  information: 

•  the  application  name 

•  a  short  application  description  for  use  in  PC  Dugout’s  application  menu 

•  a  one-  or  two-page  text  description  of  the  application 

a  version  number  to  help  PC  Dugout  keep  track  of  revisions. 

The  Application  Index  File 

As  part  of  the  submission  process,  PC  Dugout  generates  an  application  index  file  that  contains  the 
filename,  number  of  characters,  and  CRC  code  of  each  file  in  the  application.  Tliere  are  two  record  types 
in  an  application  index  file.  The  APPL  record  contains  the  application  name  and  version  number.  FILE 
records  contain  the  PC  filename,  number  of  characters  in  the  file,  and  CRC  code  for  the  file.  There  is  a 
FILE  record  for  each  file  in  the  application. 

Once  tlie  index  file  has  been  generated,  a  CRC  value  is  calculated  for  the  index  file  itself.  The 
index  file  CRC  is  not  stored  as  part  of  the  index  file  because  editing  the  file  to  include  the  CRC  value 
would  change  the  value  of  the  index  file’s  CRC.  Instead  the  index  file’s  CRC  value  is  stored  with 
applicafior,  data  in  the  Application  Database  Table  described  in  the  following  section. 

Computing  the  index  CRC  value  provides  a  way  to  ensure  that  PC  Dugout  is  using  the  proper 
index  file  when  checking  the  application  files.  The  index  file  cannot  be  changed  by  the  user  because  an 
invalid  index  file  is  automatically  replaced  by  the  mainframe.  A  sample  application  index  file  is  shown 
in  Figure  3. 
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Table  1 


Machine  Identification  and  Registration  Items 


PCDID — A  unique  integer  that  identifier  the  PC  record.  This  field  is  used  to  identify  the  user’s  PC  and 
to  link  user  information  with  other  database  tables.  That  is,  PCDID  is  used  as  an  external  key  in 
join  operations.  This  field  cannot  be  updated  by  the  user. 

PAXID — ^The  PAXID  used  in  registering  the  user’s  PC.  This  is  the  PAXID  that  has  PC  DUGCUT  as  an 
option  in  the  main  PAX  menu,  atid  helps  to  identify  the  user  associated  with  this  PC.  The  field  can 
be  updated  by  the  user  along  with  other  address  information. 

MAILID — ^The  PAXID  that  is  to  receive  PAX  Mail  messages.  It  is  normally  the  same  as  the  PAXID 
field,  but  can  be  changed  by  the  user. 

FDATE — The  first  date  this  PC  was  used  to  access  PC  Dugout  (registration  date).  It  is  not  changed  by 
the  user. 

LDATE — ^The  last  date  this  PC  was  used  to  access  PC  Dugout.  It  is  updated  automatically  as  part  of  the 
identification  procedure. 

FNAME,  LNAME — ^These  fields  are  used  to  record  the  user’s  first  and  last  names.  Two  fields  are  used 
to  allow  the  sorting  of  administrative  reports  by  last  name. 

CITY,  STATE,  ZIP — ^These  fields  are  used  to  record  postal  address  information.  They  are  broken  out 
to  facilitate  selection  of  users  and  reports. 

ADDRl,  ADDR2,  ADDR3 — ^These  are  additional  address  lines  to  be  used  in  conjunction  with  CITY, 
STATE,  and  ZIP. 

PHONE — ^The  user’s  telephone  number  with  area  code. 


APPL 

TEST  2.20 

FILE 

PCDCHECK . C 

8102 

DE7E 

FILE 

CRC16.H 

2592 

E564 

FILE 

HEXINT.H 

742 

B1E3 

FILE 

CHECKFIL.H 

1151 

F835 

There  are  two  record  types  in  an  application  index  file.  The 
APPLication  record  contains  the  application  name  and  version  number. 
FILE  records  contain  the  PC  filename,  number  of  characters  in  the  file, 
and  CRC  code  for  the  file.  There  is  a  FILE  record  for  each  file  in  the 
application. 


Figure  3.  Sample  application  index  file. 
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The  Application  Database  Table 

PC  Dugout  uses  a  database  table — the  Application  Table — to  keep  track  of  all  current  applications. 
The  types  of  data  included  in  an  application  record  arc  shown  in  Table  2. 


Application  Registration 

Users  may  view  a  list  of  all  applications  available  through  PC  Dugout  and  may  register  for  any  of 
them.  When  a  user  registers  for  an  application,  PC  Dugout  adds  a  record  in  the  mainframe  User- 
Application  Table  which  contains  the  user’s  machine  ID,  the  application  name,  and  the  user’s  application 
status.  The  status  is  first  set  to  indicate  that  the  application  has  not  been  installed  since  the  program  files 
have  not  yet  been  moved  to  the  PC.  The  application  directory  is  then  created  on  the  PC  and  a  copy  of 
the  application  index  file  is  transferred  to  the  PC. 

At  that  point  there  are  two  methods  available  to  complete  the  installation  process:  the  files  may  be 
downloaded  from  the  mainframe  or  loaded  into  the  directory  by  the  user  from  a  distribution  diskette. 
When  the  files  have  been  moved  to  the  proper  location,  the  application  status  on  the  mainframe  can  be 
updated  by  entering  the  command  that  verifies  applications.  This  procedure  compares  the  calculated  CRC 
code  for  each  application  file  on  the  user’s  PC  against  the  value  recorded  in  the  application  index  file. 
If  all  files  are  correct,  the  mainframe  status  is  cleared,  indicating  the  application  has  been  successfully 
transferred. 

A  record  is  maintained  in  the  SQL/DS  database  for  each  installation  of  an  application  on  a  PC.  This 
record  contains  the  current  application  status  and  provides  a  link  to  user  and  application  information.  The 
status  field  is  updated  each  time  the  application  is  checked  on-line.  When  a  new  application  version  is 
released  by  the  PC  Dugout  coordinator,  all  registered  users  are  flagged  to  indicate  that  revisions  are 
necessary.  The  data  elements  in  the  User-Application  Table  are  listed  in  Table  3. 


Application  Verification  and  Distribution 

Users  can  check  the  validity  of  their  PAX/PC  applications  by  selecting  the  validation  (Update) 
Oi  tion  from  the  PC  Dugout  Application  Menu.  Users  must  select  this  option  to  complete  the  process  of 
installing  or  updating  an  application  on  their  PC.  After  the  user  selects  the  application  to  check,  the 
mainframe  invokes  the  application  validation  program  (which  resides  on  the  user’s  PC).  The  Update 
program  uses  the  application  index  file,  described  previously,  to  test  the  status  of  an  application’s  files. 
CRC  values  stored  in  the  index  file  are  used  to  check  an  application’s  individual  files.  When  the 
mainframe  invokes  the  validation  program,  the  following  information  is  also  supplied: 

•  the  filename  of  the  index  file  to  be  used 

•  the  index  file’s  CRC  value 

•  the  PC  subdirectory  in  which  the  application  was  installed. 

The  validation  program  is  written  in  C,  and  checks  over  8000  characters  per  second  on  a  4.77  MHz 
PC,  the  slowest  machine  likely  to  be  used.  'Phis  allows  an  application  of  a  half-million  bytes  to  be 
completely  tested  in  about  1  minute.  Newer,  faster  machines  take  even  less  time  to  validate  applications. 


21 


Table  2 


Application  Table 
mUG()UT.PCDAPPLS) 


APPLNAME — An  eight-character  application  name.  It  must  be  unique,  as  no  two  applications  arc 
permitted  the  same  name.  Additionally,  two  different  versions  of  the  same  application  cannot  be 
distributed  under  the  same  name. 

APPLVER — A  floating  point  number  (two  I'lgits  and  two  decimal  positions)  to  identify  which  version 
of  the  application  is  being  distributed.  When  this  number  is  changed,  all  users  registered  for  the 
application  arc  flagged  as  out-of-date. 

APPLDESC — A  40-charactcr  short  description  of  the  application. 

PAXID — ^The  PAXID  used  by  the  system  developer. 

APPLDATE — ^The  date  that  the  current  version  of  the  application  was  released  to  user 

APPLCRC — The  calculated  CRC  result  for  the  application  index  file.  This  is  used  to  ensure  the  correct 
index  file  is  used  to  check  all  files. 

APPLCOUNT — ^The  total  number  of  files  comprising  this  application. 


Table  3 

User-Application  Table  Items 
(DUGOUT.USERAPPL) 


APPLNAME — The  name  of  the  application  .supported  by  PC  Dugout. 
APPLVER — ^The  version  number  of  the  application  installed  on  the  PC. 
PCDID — ^The  identification  number  of  the  PC  the  application  is  installed  on. 
UADATE — ^Thc  date  the  application  was  last  verified  on  the  PC. 

VERDATE — ^The  date  the  application  was  last  modified  in  PC  Dugout. 
UASTATUS — The  application  status  as  of  the  la.st  verification. 

APPLDISK — The  PC  Di.sk  in  which  the  application  is  installed. 

APPLDIR — ^Thc  PC  Directory  in  which  the  application  is  installed. 
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File  Validation  Methods 


The  validation  of  each  file  in  an  application  by  the  Update  program  has  two  major  functions: 

•  to  find  out  if  the  required  file  exists 

•  to  find  out  if  the  contents  of  the  file  are  correct. 

DOS  provides  functions  to  determine  if  a  file  exists.  For  files  that  are  not  critical  to  the  integrity 
of  an  application,  these  DOS  functions  may  be  sufficient.  A  user  may  have  a  file  with  report  headings 
to  he  customized  with  the  installation’s  name  and  address,  for  example.  In  this  case,  the  file  is  not 
critical;  the  system  is  primarily  interested  in  the  fact  that  the  file  exists  and  contains  data.  The  procedure 
for  verifying  this  is  relatively  straightforward  since  the  capability  is  built  into  DOS. 

The  determination  of  a  file’s  contents  presents  more  of  a  challenge  because  DOS  has  no  built-in 
ability  to  accomplish  this.  Several  approaches  are  possible.  One  can  either  test  attributes  associated  with 
the  file,  or  test  the  contents  of  the  file  directly.  Testing  attributes  can  be  faster  but  it  is  not  as  accurate. 

One  attribute  that  can  be  tested  is  the  size  of  a  file.  This  is  not  a  very  satisfactory  test  because 
many  data  files  remain  the  same  size  even  when  the  contents  are  changed.  For  example,  20  quarters  of 
economic  inflation  factors  will  always  remain  the  same  size  regardless  of  the  values  for  the  factors. 

Date/Time  stamps  are  another  attribute  that  can  be  tested,  but  this  approach  requires  files  to  be 
installed  on  the  PC  with  a  specific  datc/tinc  stamp.  This  field  can  be  changed  by  programs  that  write  to 
the  file  or  by  utilities  that  can  “fool”  PC  D  igout  into  accepting  old  or  modified  versions  of  files. 

Checksums  provide  an  approach  in  which  the  actual  contents  of  a  file  (as  opposed  to  the  attributes) 
arc  tested.  This  method  requires  the  file  to  be  opened  and  read  as  a  string  of  data.  The  character  values 
are  added  together  and  a  final  sum  is  produced  that  can  be  used  for  comparison.  Unfortunately,  this 
approach  does  not  detect  all  changes  For  example,  a  file  containing  the  data  value  “1.0”  could  be 
changed  to  “0.1”  without  altering  the  checksum.  This  approach  docs  not  provide  enough  protection  to 
assure  the  integrity  of  Dugout. 

CRC  checkvalues  provide  an  improved  alternative  to  checksums.  CRC  values  have  been  used 
historically  in  modems  and  disk  drives  to  detect  errors  in  character  streams.  The  CRC  uses  a  division 
process  and  modulo-2  arithmetic  on  the  character  stream  to  calculate  a  checkvalue.  The  calculation  of  the 
CRC  is  sensitive  to  both  the  characters  making  up  a  file  and  the  order  m  which  they  occur.  A  16  bit  CRC 
checkvalue  is  used,  which  is  expressed  in  PC  Dugout  as  4  hexadecimal  digits  (0000,  1BA7,  etc.).  Using 
a  CRC  value  provides  assurance  that  no  deviations,  accidental  or  otherwise,  occur  anywhere  in  the  file. 

The  CRC  algorithm  used  by  PC  Dugout  does  not  take  significantly  longer  to  compute  than  a 
checksum.  Each  character  checked  is  used  as  an  index  in  a  table  of  combining  values.  These  combining 
values  are  then  XOR’ed  with  the  previous  CRC  accumulator,  avoiding  the  need  for  time-consuming 
divisions  or  bit  rotations. 

As  mentioned  earlier,  a  CRC  value  is  computed  for  each  application  file  when  the  application  is 
installed  in  PC  Dugout.  This  value  is  later  compared  to  the  values  computed  on  user’s  PCs.  A  special 
CRC  value  of  0000  is  used  for  files  whose  contents  arc  unimportant  to  the  integrity  of  Dugout. 
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The  Validation  Report 

The  validation  program  generates  a  validation  report  containing  several  record  types  that  arc 
processed  by  the  mainframe.  These  records  supply  the  name  of  the  application  being  tested,  where  it  is 
installed  in  the  user’s  machine,  the  amount  of  disk  space  available,  which  version  of  the  PC  Dugout 
verification  program  was  used  to  generate  the  report,  and  status  information  for  the  individual  application 
files.  Information  listed  for  each  file  in  the  application  includes: 

•  the  PC  filename 

•  the  number  of  characters  the  file  should  have 

•  the  number  of  characters  actually  found  in  the  file 

•  the  correct  CRC  for  the  file 

•  the  calculated  file  CRC. 

A  sample  validation  report  is  in  Figure  4. 

This  validation  report  contains  several  different  record  types: 

•  CHECK  indicates  the  version  of  the  PC  Dugout  program  that  generated  the  report 

•  CDIR  shows  the  current  directory  of  the  application  on  the  user’s  PC 

•  DISK  shows  the  amount  of  free  disk  space  on  the  indicated  drive — values  listed  are  the  sector  size, 
number  of  sectors  per  allocation  unit,  number  of  free  allocation  units,  and  the  number  of  allocation  units 
currently  in  use 

•  INDEX  lists  the  index  file  name  used  to  check  the  application,  followed  by  the  index  file  CRC 

code 


•  APPL  is  a  copy  of  the  application  record  supplied  from  the  application  index  file  (Figure  3) 

•  FILE  lists  file  information  for  each  file  in  tlie  application,  including  filename,  number  of  characters 
and  CRC  code  from  the  application  index  file,  and  the  number  of  characters  and  CRC  code  calculated  for 
the  user’s  file. 

Each  record  begins  with  a  status  code  that  indicates  the  success  or  failure  of  the  processing 
associated  with  the  record.  For  example,  PC  Dugout  will  indicate  a  missing  index  file  by  setting  the  status 
code  to  2.  A  file  with  the  incorrect  CRC  will  be  given  a  status  code  of  1.  A  status  code  of  0  indicates 
successful  completion  of  the  operation. 

Determination  of  Files  To  Update 

When  the  validation  report  is  completed,  a  copy  is  transferred  to  the  mainfr,une.  The  mainframe 
reads  the  report,  evaluates  the  status  of  the  application  on  the  user’s  PC,  and  uses  the  results  to  revise  the 
User  Application  Table  in  the  mainframe  database.  The  mainframe  then  determines  what  additional 
actions  should  be  taken.  If  the  application  index  file  is  eitlier  incorrect  or  missing,  a  new  index  file  is 
moved  to  the  user’s  PC  and  the  validation  is  repeated  once.  If  any  file  is  missing  or  incorrect,  and  fails 
the  CRC  test,  it  is  added  to  a  list  of  PC  files  that  need  to  be  replaced.  Two  running  totals  are  kept:  one 
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0  CHECK  0.03 
0  CDIR  D:\TEST 

0  DISK  D:  512  8  87  2293 

0  INDEX  D:\DUGOUT\TEST.IDX  1030 
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FILE 
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CRC16.H 
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0 
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CHECKFIL.H 
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1151 
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Figure  4.  Sample  validation  report. 


of  the  number  of  characters  in  the  obsolete  files,  and  the  other  of  the  number  of  characters  in  the  correct 
files. 

The  information  from  the  validation  report  is  combined  with  another  PC  Dugout  file  on  the 
mainframe,  the  CMS  cross-reference  file.  For  each  PC  file  in  the  application,  the  cross-reference  file 
provides  the  name  of  the  CMS  file  in  which  it  is  stored  by  PC  Dugout  and  an  estimate  of  how  long  the 
file  will  take  to  transmit  at  1200  baud.  Figure  5  contains  a  sample  CMS  cross  reference  file  for  the  TCST 
application. 

Determination  of  Disk  Space 

A  check  is  made  to  find  out  if  the  user  has  enough  room  on  his  PC  to  install  all  of  the  files  that 
need  replacement.  The  total  free  disk  is  added  to  the  total  size  of  all  incorrect  files.  This  is  the  amount 
of  space  available  for  the  update.  The  total  size  of  the  replacement  files  is  then  compared  with  the  total 
space  available  to  determine  if  sufficient  room  is  available  on  the  user’s  PC. 


Validation  Summary  Report  and  File  Tranter 

When  all  the  above  information  is  collected  and  the  total  number  of  files  requiring  replacement  is 
determined,  the  user  is  presented  with  a  report.  The  report  contains  summary  information,  including 
application  name,  date  checked,  and  the  number  of  files  in  error.  If  no  files  are  incorrect,  the  user  is 
informed  that  there  are  no  files  to  fix,  and  the  validation  process  is  completed. 

If  there  is  not  enough  disk  space  on  the  PC,  the  user  is  issued  a  message  to  that  effect  and  the 
installation  process  stops.  If  there  is  enough  disk  space,  Uie  user  is  told  which  files  will  be  replaced  and 
is  given  an  estimate  of  the  total  time  required  to  transmit  the  files  to  his  PC  (based  on  the  current  baud 
rate  and  the  time  originally  required  to  load  the  file  to  the  mainframe).  The  user  is  then  asked  if  he  or 
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4 

@TEST  GRPF0001@PCDCHECK.C@  A§50 
@TEST  GRPF0002@CRC16.H@  A@17 
@TEST  GRPF0003§HEXINT.H@  A§10 
@TEST  GRPF0004@CHECKFIL.H@  A§12 


NOTE:  The  CMS  cross-reference  file  is  created  on  the  mainframe  when  an  application  is  submitted.  The  first  record  is  used  to  keep 
track  of  a  counter  used  In  generating  CMS  names  for  application  files.  This  record  indicates  the  last  sequential  number  used 
in  creating  a  filename  for  this  application.  The  remaining  records  list  the  mainframe  CMS  filenames  of  each  file  in  the 
application,  the  associated  PC  filename,  the  type  of  file,  and  tine  number  of  seconds  to  transfer  the  file  at  1200  baud. 


Figure  5.  Sample  CMS  cross-reference  file. 


she  would  like  to  proceed  with  the  file  transfer.  If  the  user  agrees,  the  file  transfer  is  initiated  using 
theprotocol  that  matches  the  user’s  communications  package.  Alternatively,  the  user  may  decline  the 
transfer  and  complete  it  at  another  time,  or  load  the  files  from  diskette.  A  sample  validation  terminal 
session,  including  a  validation  summary  report,  is  shown  in  Figure  6.  Items  requiring  user  response  are 
underlined. 


Local  Operations 

Most  PC  Dugout  activities  are  performed  under  the  control  of  the  PAX  mainframe.  This  is 
necessary  to  keep  the  PC  Dugout  central  database  current.  However,  two  operations  available  through  the 
menu  system  can  be  performed  locally  as  stand-alone  applications  on  the  PC  without  accessing  the  PAX 
system. 

The  first  of  these  stand-alone  operations  is  a  program  that  permits  the  user  to  update  name  and 
address  information  using  a  ftill-screen  format.  This  operation  rewrites  the  PC  Dugout  identification  file, 
which  is  used  to  update  the  SQL  machine  identification  table  the  next  time  the  PC  Dugout  option  in  PAX 
is  selected  by  the  user. 

The  other  program  designed  for  local  operation  is  an  application  update  procedure  that  can  reduce 
the  cost  and  delay  of  downloading  files  over  telephone  lines.  It  is  similar  to  the  application  verification 
procedure  used  by  the  mainframe,  but  differs  in  some  important  ways.  This  program  prompts  the  user 
for  the  name  of  the  application  that  needs  to  be  verified  or  updated.  The  procedure  then  looks  for  the 
appropriate  application  index  file  on  the  PC  and  uses  it  to  examine  the  application.  Since  the  mainframe 
database  is  not  accessible  when  the  PC  is  logged  out  of  PAX,  this  program  has  no  way  to  verify  that  the 
index  file  is  correct  or  to  check  the  current  version  of  the  application.  Also,  instead  of  generating  a  report 
to  be  used  by  the  mainframe,  it  presents  the  information  directly  to  the  user.  If  files  are  missing  or  the 
CRCs  do  not  match,  the  user  is  prompted  for  a  disk  path  for  the  proper  files.  This  permits  the  user  to 


26 


Enter  command:  Registered  List  Update  Drop  Add  Type  or  Quit 
>u 

Registered  Applications 
#  Status  Name  Ver.  Directory 


1  0  TEST  2.20  D:\TEST 


Select  application  numbers  (1  to  1): 

>1 

Now  checking  application  TEST  1030  D  \TEST 

Now  verifying  TEST  files.  D:\DUG0UT 

445  BYTES,  17  SECONDS,  26  CPS 

Index  file  and  CRC  are:  D:\DUGOUT\TEST.IDX  1030 
Processing  results  of  application  verification 

+ - - - + 

Application :  TEST 
Version  : 

Directory  :  D:\TEST 

Verified  on:  12  Jul  1989  05:19:02 

Status  :  OK 

Files  in  application  :  4 
Total  application  size:  12587 

Total  space  available  on  disk  D:  409600 

No  errors  found  to  fix 

Enter  command:  Registered  List  Update  Drop  Add  Type  or  Quit 
> 


Figure  6.  Sample  application  validation. 


insert  a  distribution  or  backup  diskette  and  automatically  regenerate  the  files.  The  final  results  of  this 
operation  are  noted  in  the  PC  Dugout  identification  file,  which  is  used  to  update  the  mainframe  database 
when  the  user  next  accesses  PC  Dugout  through  PAX. 

This  local  approach  to  applications  updating  can  be  used  to  reduce  time  and  money  spent  download¬ 
ing  application  files  over  phone  lines,  especially  if  several  PCs  in  an  office  are  used  for  the  same 
application.  After  this  procedure,  all  the  user  has  to  do  is  access  PAX  and  have  PC  Dugout  verify  that 
the  application  is  properly  installed.  This  followup  serves  as  a  double  check  for  the  users  while  informing 
the  central  database  of  the  application’s  status  on  the  user’s  PC. 
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Additional  local  PC  Dugout  operations  may  be  added  in  the  future  to  further  reduce  the  cost  of 
mainframe  processing  and  enhance  user  interfaces. 


Application  Distribution  Test  and  Cost  Analysis 

PC  ECONPACK,  one  of  the  Army’s  required  economic  analysis  software  products,  was  used  to  test 
the  distribution  capability  of  PC  Dugout.  PC  ECONPACK’s  user  base  consists  of  1000  sites  worldwide, 
aU  of  which  have  access  to  the  PC  Dugout  subsystem  via  Tymnet  and  PAX.  The  initial  distribution  of 
PC  ECONPACK  is  done  on  a  set  of  six  low-density  diskettes.  The  cost  incurred  per  distribution  site  is 
calculated  to  be  $80.  The  breakout  is  shown  in  Table  4. 

The  total  manual  distribution  cost  of  $80,000  is  incurred  each  time  a  new  version  is  slated  for 
release.  With  two  updates  a  year,  the  price  of  distributing  PC  ECONPACK  is  $160,000  annually. 

The  cost  to  distribute  the  same  application  using  PC  Dugout  is  not  only  lower  in  absolute  terms, 
but  more  cost-effective  as  well.  The  total  PC  ECONPACK  application  consists  of  1.7  million  bytes  of 
information,  compressed  to  1.2  million  bytes  to  reduce  the  transfer  lime.  The  cost  to  distribute  PC 
ECONPACK  to  1000  user  sites  was  calculated  at  $72,000  by  Huntsville  Division,  which  is  responsible 
for  the  distribution  of  PAX  applications  and  administration  of  PC  Dugout.  The  real  savings  are  realized 
when  an  update  is  needed  because,  when  distributed  on  line  by  PC  Dugout,  it  is  not  necessary  to  transfer 
the  entire  application — only  selected  parts  that  have  been  updated.  By  design,  PC  Dugout  can  be  applied 


Table  4 


Cost  Per  Each  PC  ECONPACK  Distribution 


Materials: 

Set  of  six  diskettes  at  $0.75  per  diskette  $  4.50 
Contracted  duplication  at  $1.50  per  diskette  $  9.00 
Mail  cost  per  6  disk  set  $  3.50 

Office  supplies  $  3.50 

Labor  (at  $12  per  hour): 

Preparation  of  instructions  (15  min)  $  3.00 

In-house  reproduction  cost  per  set  (15  min)  $  3.00 

Assemble  complete  package  (20  min)  $  4.00 

Accomplish  mailing  $  1.50 

Installation  at  user  site  (2  1/2  hr)  $30.00 

Hotline  support  (1  1/2  hr)  $18.00 

Manual  Distribution  Cost  per  set:  $80.00 

Distribution  Cost  for  1000  users:  $80,000.00 
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to  update  a  previously  distributed  application  after  the  fact.  The  feature  allows  the  applications  developer 
to  use  a  combination  of  traditional  distribution  routes  and/or  PC  Dugout.  In  this  way  all  of  the  labor 
charges  listed  above,  with  the  exception  of  hotline  support,  are  eliminated. 
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6  CONCLUSION 


This  report  has  described  the  investigation,  technical  challenges,  and  development  of  PC  Dugout, 
a  transparent  communications  software  capability  for  use  in  the  PAX  system  environment.  PC  Dugout 
is  designed  to  increase  productivity  by  enabling  previously  centralized  processing  tasks  to  be  accomplished 
by  local  PCs.  PC  Dugout  is  a  user-friendly  system  that  provides  an  efficient,  reliable  method  for 
distributing  and  updating  PC  applications  transparently  while  exercising  an  effective  level  of  management 
to  protect  the  integrity  of  the  system.  PC  Dugout  reliably  makes  sure  that  users  of  PAX  applications  are 
using  the  most  current  versions  of  these  applications,  thus  ensuring  that  information  provided  from  the 
field  is  consistent  in  substance  and  presentation. 
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APPENDIX:  AN  EVALUATION  OF  PC  COMMUNICATIONS  PACKAGES  FOR  USE  WITH 
DUGOUT 


I  Introduction 


The  Programming,  Administration,  and  Execution  (PAX)  system  is  an  extensive  Army  data  processing 
system  serving  hundreds  of  users  worldwide.  Traditionally,  PAX  has  consisted  of  several  large 
mainframe-based  applications.  With  the  advent  of  personal  computer  (PQ  technology,  some  PAX 
applications  are  being  ported  for  personal  computers.  PC  Dugout  was  designed  to  automate  the 
distribution  and  maintenance  of  these  PAX  PC  applications. 

Tym/COMM  was  the  first  PC  communications  package  supported  by  Dugout.  As  support  for  other 
communications  packages  was  desired,  Tym/COMM  was  ev^uated  and  compared  with  two  additional 
candidates — VistaCOM  and  ProComm.  The  results  of  that  analysis  are  described  in  this  Appendix. 

The  analysis  was  divided  into  two  major  areas.  First  the  communications  packages  themselves  were 
evaluated  for  their  suitability  in  the  Dugout  environment.  Then  the  file  transfer  protocols  used  by  these 
communications  packages  were  analyzed  to  determine  their  cost  of  operation  and  compatibility  with 
Dugout. 

This  appendix  is  organized  as  follows: 

•  Section  II  describes  the  Dugout  curating  environment. 

•  Section  III  lists  the  Dugout  requirements  for  communications  packages 

•  Section  IV  lists  the  Dugout  requirements  for  file  transfer  protocols 

•  Section  V  evaluates  the  XMODEM,  Kermit,  COPYPC,  and  Vista  file  transfer  protocols.  (Results  of 
cost-performance  benchmark  tests  are  included  as  an  addendum  to  this  Appendix.) 

•  Section  VI  contains  product  summaries  for  Tym/COMM,  ProComm,  and  VistaCOM,  including  recom¬ 
mendations. 


II  Dugout  Overview 

Dugout  is  a  timesharing  application  available  through  the  PAX  system  menu.  PAX  uses  an  IBM 
mainframe  mnning  under  VM/CMS,  and  utilizes  the  Tymnet  communications  letwork.  Dugout  currently 
supports  IBM  PC  compatibles. 

Dugout  is  primarily  a  file  distribution  mechanism.  It  installs  and  updates  PAX  PC  applications  on  remote 
PCs.  Dugout  is  a  mainframe  application,  but  some  Dugout  routines  are  downloaded  to  a  user’s  PC  when 
that  PC  is  registered  on  Dugout. 

Dugout  tracks  both  registered  PCs  and  applications.  Applications  consist  of  a  group  of  files  that  comprise 
the  application,  plus  an  index  file  that  identifies  the  proper  version  of  each  individual  file  in  the 
application.  Applications  can  be  installed  only  on  registered  PCs.  This  installation  process  tracks  the 
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application.  Applications  can  be  installed  only  on  registered  PCs.  This  installation  process  tracks  the 
version  and  status  of  each  application  on  each  PC. 

Dugout  Operation 

The  status  of  a  user’s  PAX  PC  application  is  checked  by  running  a  PC  procedure  that  was  downloaded 
when  the  user’s  PC  was  registered  on  Dugout.  The  results  of  this  PC  procedure  are  then  uploaded  to  the 
mainframe  and  interpreted.  Any  files  in  need  of  update  or  replacement  are  transferred  over  the  network 
to  the  PC. 

To  save  transmission  costs  and  reduce  the  amount  of  mainframe  disk  storage  required,  Dugout  packs 
(compresses)  most  (but  not  all)  application  files  into  archives,  which  are  binary  files.  Once  an  archive 
has  been  transferred  from  mainframe  to  PC,  Dugout  issues  a  DOS  command  to  unpack  the  archived  file, 
placing  the  new  file  in  the  proper  directory  on  the  proper  disk.  The  archive  is  then  erased.  It  is 
imperative  that  this  operation  be  completely  automated  for  accuracy  and  user  convenience. 

Because  ease  of  use  has  been  a  primary  design  consideration  in  Dugout,  the  user  interface  was 
implemented  as  a  series  of  menus  rather  than  via  the  DOS  command  line.  All  operations  are  available 
to  users  as  menu  choices,  and  the  file  transfers  and  application  validations  are  performed  automatically, 
without  requiring  user  intervention. 


Ill  Communications  Package  Requirements 

As  described  in  Section  II,  the  high  degree  of  user-friendliness  and  control  needed  in  Dugout  requires  the 
automation  of  all  Dugout  operations  on  the  PC.  Users  must  be  able  to  have  an  ajiplication’s  status 
checked,  and  outdated  files  replaced  on  their  PC  without  entering  additional  commands.  Also,  future 
enhancements  may  require  additional  automation,  such  as  updating  applications  overnight,  without  any 
intervention  bv  the  user.  In  order  to  achieve  this  level  of  automation,  communications  packages  must  be 
integrated  into  Dugout.  This  requires  that  the  packages: 

•  permit  the  execution  of  DOS  commands  or  PC  programs  under  the  control  of  the  mainframe 
application 

•  support  bidirectional  file  transfers  Initiated  by  the  mainframe. 

The  communications  packages  were  analyzed  and  evaluated  in  terms  of  how  well  they  meet  these  two 
primary  requirements  (see  Section  VI). 


IV  File  Transfer  Protocol  Requirements 

Dugout  must  transfer  files  from  one  computer  to  another.  The  transfer  of  files  requires  the  cooperation 
of  both.  The  rules  for  file  transfer  followed  by  each  unit  arc  collectively  called  a  protocol.  The  program 
that  implements  these  niles  is  called  a  driver.  Mo.st  PC  communications  packages  have  drivers  that 
support  several  different  protocols. 
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To  be  viable  in  the  Dugout  environment,  file  transfer  protocols  must  include  have  the  following  features: 

•  operation  in  the  PAX  environment  (IBM  VM/CMS  and  Tynmet) 

•  low-cost  file  transfers 

•  the  ability  to  transfer  both  text  and  binary  files 

•  the  ability  to  transfer  files  without  modification 

•  a  corrective  file  transfer  mechanism 

•  mainframe  file  compatibility  with  other  protocol  drivers. 


The  following  sections  describe  these  criteria  in  more  detail. 

Operation  in  the  PAX  Environment 

The  protocols  available  for  Dugout  operations  are  limited  to  those  for  which  IBM  VM/CMS  drivers  are 
available.  If  there  is  no  program  available  for  the  mainftame  that  follows  the  protocol  conventions,  the 
protocol  cannot  be  used.  In  addition,  the  drivers  must  be  able  to  use  the  Tymnet  communications  network. 
Drivers  currently  available  within  the  PAX  environment  are  COPYPC,  Kermit,  Vista,  and  XMODEM. 

Low-Cost  File  Transfers 

As  many  as  12  separate  PAX-PC  applications,  each  containing  many  files,  will  be  distributed  and  updated 
through  Dugout.  The  applications  and  updates  will  be  downloaded  to  hundreds  of  PAX  users  worldwide. 
Thus,  it  is  imperative  for  any  driver  used  in  Dugout  to  provide  relatively  low-cost  file  transfers. 

Transfer  of  Both  Text  and  Binary  Files 

File  transfer  protocols  used  by  Dugout  must  be  able  to  transfer  both  text  and  binary  files  since  Dugout 
requires  both  types  of  files  for  operation.  Text  files  contain  alphanumeric  information  in  a  form  suitable 
for  reading.  The  characters  in  these  files  are  translated  between  ASCII  and  EBCDIC  so  they  can  be  used 
both  on  the  PC  and  the  mainframe.  Binary  files  are  typically  computer  program  files,  which  are  not 
intended  for  people  to  read.  Archive  files  are  a  special  kind  of  binary  file  in  which  one  or  more  files 
(either  text  or  binary)  are  compressed  and  placed  in  a  library  file. 

Most  Dugout  application  files  are  compressed  into  archives  for  distribution,  and  unarchived  on  the  usf’s 
PC  automatically.  This  operation  saves  disk  storage  within  Dugout,  and  reduces  the  time  and  connect 
charges  associated  with  the  file  transfers. 

File  Transfers  Without  Modification 

Dugout  checks  the  validity  of  installed  PC  applications  by  calculating  a  CRC  value  for  each  application 
file  on  the  PC,  and  comparing  it  with  the  proper  CRC  value  stored  on  the  mainframe.  If  the  CRC  values 
do  not  match,  a  correct  version  of  the  application  file  is  downloaded  to  the  PC.  The  CRC  value 
computation  requires  that  an  exact  image  of  the  file  be  transferred. 
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Not  all  flic  transfer  protocols  can  accommodate  this  directly.  XMODEM,  for  example,  docs  not.  All  files 
iransfcrrcd  by  XMODEM  arc  sent  in  full  128  character  blocks.  Thus,  a  file  originally  20  characters  long 
will  end  up  having  a  length  of  128  characters  after  it  is  transferred.  The  file  will  then  have  a  CRC  value 
different  from  the  proper  CRC  value  stored  on  the  mainframe. 

Corrective  File  Transfer 

A  corrective  file  transfer  capability  can  detect  and  correct  transmission  errors  such  as  those  due  to  line 
noise.  This  feature  is  required  for  protocols  used  with  Dugout  to  provide  an  acceptable  reliability  standard 
for  file  transfers. 

Mainframe  File  Format  Compatibility 

Any  binary  PC  files  moved  to  the  mainframe  with  one  protocol  must  be  usable  by  all  other  protocol 
drivers.  That  is,  if  a  file  is  moved  up  to  the  mainframe  using  XMODEM,  for  example,  it  should  be  able 
to  be  successfully  downloaded  to  a  PC  with  COPYPC.  The  PAX  XMODEM  and  COPYPC  drivers  use 
compatible  mainframe  file  formats.  An  option  has  also  recently  been  added  to  the  Vista  driver  to  make 
its  files  compatible  with  COPYPC  and  XMODEM. 


V  Evaluation  of  File  Tran.sfer  Protocols 

This  section  summarizes  the  capabilities  of  XMODEM,  Kermit,  COPYPC,  and  Vista.  The  results  of  six 
cost-performance  benchmark  tests  of  the  protocols  arc  included  in  the  addendum  to  this  Appendix. 

XMODEM 

XMODEM  is  a  public  domain  protocol  designed  primarily  for  PC-to-PC  file  transfers.  XMODEM  is  used 
widely,  and  most  PC  packages  on  the  market  today  support  XMODEM  file  transfers.  XMODEM  transfers 
require  use  of  the  full  8-bit  characio.  set,  a  requirement  not  satisfied  by  all  timesharing  computer  networks. 
Tymnet,  however,  does  permit  8-bit  operation. 

XMODEM  also  transmits  fixed  128-character  packets,  and  requires  an  acknowledgment  for  each  packet 
transmitted  before  the  next  can  be  sent.  This  subjects  the  transfer  to  network  and  host  delays,  which 
seriously  degrade  the  effective  character  transmission  rate.  Even  though  it  sends  fewer  characters  than 
the  other  methods  studied,  it  actually  takes  longer  to  transmit  equivalent  files. 

Also,  as  noted  previously,  the  fixed  128-byte  blocks  modify  the  file  being  transmitted.  It  is  possible  for 
Dugout  to  get  around  this  problem  if  the  application  files  are  archived  before  transmission  and  unpacked 
later.  This  causes  the  archive  file  to  grow  to  the  next  higher  multiple  of  128  characters,  but  has  no  effect 
on  the  archive.  When  the  application  files  are  unpacked,  they  retain  their  original  size  and  CRC  values. 
If  XMODEM  is  supported  as  a  file  transfer  option  within  Dugout,  all  application  file  transfers  must  be 
performed  using  archives.  This  would  require  a  small  change  in  certain  procedures  used  in  the  Dugout 
prototype. 

Kermit 

Kermit  is  a  public  domain  protocol  used  with  other  Kermit  communications  programs  on  mainframes  and 
PCs.  Prior  work  with  this  driver  indicated  that  only  text  files  could  be  transferred,  and  that  the  cost 
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transmission  units  (TRUs),  character  input/output,  and  connect  time)  was  prohibitive.  Since  Dugout 
requires  the  transmission  of  binary  files,  Kermit  was  not  benchmariced. 

COPYPC 

COPYPC  is  a  proprietary  file  transfer  protocol  by  McDonnell  Douglas  Corp.  used  with  Tym/COMM  on 
the  PC.  COPYPC  automatically  compresses  and  decompresses  files  to  try  to  reduce  the  number  of 
characters  transmitted,  but  this  works  better  on  text  files  than  binary  files.  COPYPC  does  not  exhibit  the 
same  delays  due  to  packet  acknowledgement  that  XMODEM  does.  In  addition,  the  TRUs  used  by  this 
package  are  minimal,  and  the  files  transmitted  are  not  modified.  This  package  was  implemented  in  the 
prototype  version  Dugout. 

VISTA 

Vista  is  a  proprietary  file  transfer  protocol  by  Control  Data  Corp.  (CDC).  Versions  are  available  for  IBM 
370-style  mainframes  and  several  other  host  systems.  The  PC  side  is  incorporated  into  the  VistaCOM 
communications  program.  The  protocol  does  not  require  8-bit  communications  lines,  and  it  incorporates 
a  compression  technique  to  automatically  reduce  the  number  of  characters  transmitted.  The  number  of 
characters  used  to  transmit  files  is  comparable  to  COPYPC. 

The  number  of  TRUs  required  by  the  driver  program  to  send  or  receive  a  file  is  much  higher  than  either 
XMODEM  or  COPYPC.  In  particular,  the  cost  to  download  files  from  mainframe  to  PC  is  significantly 
higher  than  the  cost  to  upload  files.  This  is  not  acceptable  in  Dugout  since  the  primary  direction  of 
transfer  is  from  the  mainframe  to  many  PCs.  Also,  the  Vista  program  module  is  so  large  that  the  cost  of 
just  loading  the  program  into  memory  in  preparation  for  execution  is  significant. 

The  protocol  uses  a  sliding  window  (several  packets  transmitted  before  acknowledgment),  and  it  permits 
simultaneous  bidirectional  transfer  of  files,  effectively  doubling  the  line  speed  when  files  can  be  sent  and 
received  at  the  same  time. 

Although  cost  prohibits  Vista  from  being  an  attractive  alternative  for  Dugout,  is  has  two  potential 
advantages  that  may  be  val»jable  for  future  PAX  applications: 

•  its  simultaneous  upload  and  download  capability 

•  the  use  of  file  transfer  queues  to  transfer  many  files  in  one  session. 


VI  Product  Summaries 


TymiCOMM 

Tym/COMM  is  a  product  of  the  McDonnell  Douglas  Corp.,  and  is  currently  available  in  version  4.0.  The 
package  requires  less  than  50  Kbytes  of  disk  storage — a  relatively  small  amount  of  disk  space  on  a  user’s 
PC. 

Tym/COMM  has  a  script  language  capability,  which  allows  the  user  to  name  a  sequence  of  commands 
and  save  them  for  future  use,  as  in  an  automated  logon  sequence.  This  capability  is  not  required  by 
Dugout,  but  it  may  prove  useful  in  other  applications. 
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An  escape  sequence  pcrmils  the  execution  of  DOS  commands  and  PC  programs  under  mainframe  control. 
Thus,  Tym/COMM  meets  Dugoul’s  requirements  for  automation  and  user-friendliness. 

File  transfer  protocols  supported  by  Tym/COMM  are  XMODEM  and  COPYPC.  Under  Tym/COMM, 
XMODEM  transfers  cannot  be  initiated  from  the  mainframe,  as  required  by  Dugout.  Thus,  Dugout 
requires  that  Tym/COMM  be  used  only  with  COPYPC. 

Recommendation:  Dugout  users  should  continue  to  use  Tym/COMM  with  COPYPC.  It  is  cost-effective, 
easy  to  use,  and  meets  all  Dugout  requirements. 

ProComm 

ProComm  is  a  product  of  Datastorm  Technologies,  Inc.,  and  occupies  about  200  Kbytes  of  disk  storage. 
It  is  currently  available  in  version  4.2. 

Like  Tym/COMM,  ProComm  has  a  script  language  capability,  but  it  does  not  support  the  execution  of 
DOS  commands  under  mainframe  control.  Since  the  execution  of  DOS  or  program  commands  cannot  be 
controlled  by  the  mainframe,  ProComm  cannot  be  fully  automated  within  Dugout.  While  it  would  be 
possible  to  use  ProComm  with  Dugout,  a  lack  of  automation  would  force  users  to  perform  the  required 
operations  manually.  This  is  not  desirable  since  it  is  tedious  and  vulnerable  to  error.  Theoretically,  scripts 
could  be  written  to  partially  automate  these  operations.  However,  the  scripts  would  not  provide  full 
automation,  and  error  recovery  would  be  cumbersome.  Also,  the  support  of  different  program  versions 
would  be  untenable  from  a  maintenance  standpoint. 

ProComm  supports  12  file  transfer  protocols,  but  only  XMODEM  can  be  used  from  within  Dugout.  There 
are  no  mainframe  drivers  for  the  other  protocols. 

Recommendations:  At  this  time,  it  is  not  recommended  that  ProComm  be  actively  supported  by  Dugout. 
Although  ProComm  can  operate  with  Dugout,  other  packages  are  more  fully  compatible  with  Dugout’s 
environment  and  requirements. 

VistaCOM 

VistaCOM,  a  product  of  the  CDC,  is  designed  as  a  group  of  modules.  VistaCOM  is  part  of  a  larger  series 
of  communications  tools  offered  by  CDC.  As  installed  in  the  configuration  required  to  support  Dugout, 
the  modules  occupy  approximately  700  Kbytes  of  disk,  which  is  relatively  large  for  just  a  communications 
package. 


VistaCOM  has  a  script  language  capability.  In  addition,  through  the  use  of  the  VistaKIT  product, 
VistaCOM  can  be  incorporated  into  PC  applications,  providing  extensive  screen  and  communications 
capabilities. 

While  the  VistaCOM  program  itself  does  not  permit  the  execution  of  DOS  commands  and  PC  programs 
under  mainframe  control,  another  module  supplied  with  the  package  does,  enabling  the  product  to  be 
integrated  with  Dugout.  The  use  of  different  modules  is  explained  in  user  instructions,  but  some  users 
may  be  confused  since  VistaCOM  will  not  function  properly  with  Dugout  if  the  proper  module  is  not 
running. 
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Two  file  transfer  protocols  can  be  supported  under  Dugout:  Vista  and  XMODEM.  The  Vista  protocol 
offers  many  sophisticated  features  not  required  by  Dugout,  and  the  operation  cost  is  significantly  higher 
than  other  alternatives.  The  XMODEM  protocol  can  be  used  with  Dugout,  and  the  operating  cost  is 
roughly  equivalent  to  the  Tym/COMM-COPYPC  combination. 

Recommendations:  Because  VistaCOM  is  the  standard  communications  program  for  a  number  of  PAX 
users,  it  should  be  supported  in  Dugout  using  the  XMODEM  protocol.  Dugout  operations  should  be 
modified  to  transfer  all  files  as  archives  to  avoid  XMODEM’s  character  additions  to  transmitted  files. 

Also,  because  of  the  advanced  capabilities  of  both  VistaCOM  and  the  Vista  protocol,  their  use  in  other 
selected  PAX  PC  applications  should  be  explored. 
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ADDENDUM:  Cost- Performance  Benchmark  Results 


The  COPYPC,  Vista,  and  XMODEM  file  transfer  protocols  were  tested  for  cost  performance.  The 
following  charts  show  the  benchmark  results. 


Chart  1:  File  Transfer  Protocols  Cost  Comparison — ^TRUs 

This  chart  shows  the  mainframe  CPU  component  of  file  transfer  costs.  The  Vista,  XMODEM  and 
COPYPC  drivers  were  compared  in  the  uploading  and  dov u  nloading  of  various-size  files.  The  chart  also 
shows  TRUs  expended  versus  the  size  of  the  file  being  transferred.  Note  that  upload  costs  can  differ  from 
download  costs  within  the  same  drivers.  In  particular,  Vista  download  uses  twice  as  many  TRUs  as  Vista 
upload.  Also,  note  that  for  all  packages  TRU  usage  is  a  linear  function  of  file  size. 


Chart  2:  File  Transfer  Protocols  Cost  Compari.son — ^TlOs 

Terminal  input/output  (TIO)  is  the  number  of  characters  required  to  transmit  a  file.  The  chart  compares 
characters  transmitted  as  a  function  of  file  size.  Because  the  files  used  were  binary,  the  text  compression 
algorithms  of  Vista  and  COPYPC  had  no  effect. 


Chart  3:  File  Transfer  Protocols  Cost  Comparison — Total  Dollars 

This  chart  compares  total  cost  versus  size  of  file  transmitted.  Total  cost  includes  TRUs,  TlOs,  and 
connect  time. 


Charts  4  and  5:  Cost  Breakdown — Download  and  Upload 

These  eharts  illustrate  the  contribution  of  each  cost  component  for  four  different-size  files  for  the  tested 
protocol  drivers.  (The  smallest  file  transferred  is  the  leftmost  bar  in  each  set  of  grouped  bars;  the  largest 
file  is  the  rightmost  bar )  Note  that  the  original  Vista  (before  pcrfonnance  enhancements  were  made  for 
the  Army)  is  included  in  these  charts  to  show  the  relative  improvement  in  tuning  the  driver  for  PAX.  The 
download  and  upload  costs  are  presented  in  two  separate  charts. 


Charts  6  and  7:  Benchmark  Summarie.s — PoAvnload  and  Upload 

Chart  6  contains  download  results  and  Chart  7  contains  upload  results.  The  protocol  configurations  tested 
were: 


•  XMODEM  using  Tym/COMM 

•  XMODEM  using  VistaCOM 

•  COPYPC  using  Tym/COMM 

•  The  original  Vista  driver  using  VistaCOM 

•  The  improved  Vista  driver  using  VistaCOM. 


38 


Each  protocol  driver  was  tested  with  six  different  files,  which  were  a  variety  of  types  and  sizes 
representative  of  those  used  in  Dugout: 

File  1 — An  archive  containing  a  text  document  in  compressed  form  (8191  characters) 

File  2 — ^The  original  unarchived  text  file  that  was  used  to  generate  File  1  (21606  characters) 

File  3 — An  archive  containing  an  executable  PC  program  (21783  characters) 

File  A — ^The  original  binary  file  that  was  archived  to  generate  File  3  (51206  characters) 

File  5 — An  archive  of  several  files  of  mixed  type  (51206  characters) 

File  6 — An  archive  of  several  files  of  mixed  type  (150981  characters). 


39 


RL’s 


Chart  1;  File  Transfer  Protocols  Cost  Comparison — TRUs 


TIOs 


"O 

TD 

03 

CD 

O 

O 

a 

C 

D 

■D 

< 

,< 

P 

h- 

w 

W 

> 

> 

o 

■o 

"O 

CO 

CO 

o 

O 

Q. 

c 

D 

■O 

2 

LU 

LU 

O 

Q 

O 

o 

2 

2 

X 

X 

■D 

■D 

CO 

CO 

O 

O 

Cl 

c 

D 

30 

o 

o 

CL 

CL 

X 

X 

CL 

CL 

O 

o 

O 

o 

[) 

41 


Chart  2:  File  Transfer  Protocols  Cost  Comparison — TIOs 


Chart  3:  File  Transfer  Protocols  Cost  Comparison — Total  Dollars 


Dollars 
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Chart  4;  Download  Cost  Breakdown 


Cost  Breakdown 


+ -  Dollars  - + 


File  Type 

Size 

Minutes 

TRU 

TIO 

conn 

tru 

tio 

tot 

XMODEM  Download 

1  ARC  8191 

2.0 

1.16 

8674 

0.33 

0.06 

0.43 

0.82 

2  DOC 

21606 

5.3 

2.72 

22773 

0.88 

0.14 

1.14 

2.16 

3  ARC 

21783 

6 

3 

23000 

1.00 

0.15 

1.15 

2.30 

4  EXE 

27731 

7.0 

3.02 

29024 

1.17 

0.15 

1.45 

2.77 

5  ARC 

51206 

12.0 

5.16 

53230 

2.00 

0.26 

2.66 

4.92 

6  ARC 

150981 

35.0 

14.31 

157105 

5.83 

0.72 

7.86 

14.41 

VistaCOM- 

1  ARC 

XMODEM  Download 

8191  2 

1.3 

8715 

0.33 

0.07 

0.44 

0.84 

2  DOC 

21606 

5 

2.8 

22813 

0.83 

0.14 

1.14 

2.11 

3  ARC 

21783 

6 

3.1 

22946 

1.00 

0.16 

1.15 

2.31 

4  EXE 

27731 

7 

3.1 

29064 

1.17 

0.16 

1.45 

2.78 

5  ARC 

51206 

13 

5.3 

53270 

2.17 

0.27 

2.66 

5.10 

6  ARC 

150981 

36 

14.4 

157143 

6.00 

0.72 

7.86 

14.58 

COPYPC  Download 


1 

ARC 

8191 

1.6 

1.22 

10650 

0.27 

0.06 

0.53 

0.86 

2 

DOC 

21606 

2.7 

2.78 

17131 

0.45 

0.14 

0.86 

1.45 

3 

ARC 

21783 

4.5 

2.32 

27629 

0.75 

0.12 

1.38 

2.25 

4 

EXE 

27731 

5.0 

2.86 

33320 

0.83 

0.14 

1.67 

2.64 

5 

ARC 

51206 

10.0 

5.2 

64606 

1.67 

0.26 

3.23 

5.16 

6 

ARC 

150981 

29.0 

14.12 

189001 

4.83 

0.71 

9.45 

14.99 

VistaHOST 

Download 

1 

ARC 

8191 

1.7 

22.32 

13221 

0.28 

1.12 

0.66 

2.06 

2 

DOC 

21606 

2.5 

27.07 

18000 

0.42 

1.35 

0.90 

2.67 

3 

ARC 

21783 

4.3 

46.49 

32293 

0.72 

2.32 

1.61 

4.65 

4 

EXE 

27731 

5.0 

50.00 

33800 

0.83 

2.50 

1.69 

5.02 

5 

ARC 

51206 

10.0 

99.80 

75231 

1.67 

4.99 

3.76 

10.42 

6 

ARC 

150981 

30.0 

282.26 

221637 

5.00 

14.11 

11.08 

30.19 

VistaCOM  Vista  pcpack  Download 


1 

ARC 

8191 

2.3 

16.54 

12849 

0.38 

0.83 

0.64 

1.85 

2 

DOC 

21606 

3.0 

21.58 

17740 

0.50 

1.08 

0.89 

2.47 

3 

ARC 

21783 

4.8 

29.12 

31324 

0.80 

1.46 

1.57 

3.83 

4 

EXE 

27731 

5.2 

30.55 

32744 

0.87 

1.53 

1.64 

4.04 

5 

ARC 

51206 

11.2 

57.08 

72799 

1.87 

2.85 

3.64 

8.36 

6 

ARC 

150981 

31.2 

151.82 

214227 

5.20 

7.59 

10.71 

23.50 

Chart  6:  Download  Benchmark  Results 
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+ -  dollars  - + 


File  Type 

Size 

Minutes  TRU 

TIO 

conn 

tru 

tio 

tot 

XMODEM  Upload 

1 

ARC 

8191 

3.0 

2.00 

8679 

0.50 

0.10 

0.43 

1.03 

2 

DOC 

21606 

8.0 

5.44 

23394 

1.33 

0.27 

1.17 

2.77 

3 

ARC 

21783 

8.0 

4.10 

22910 

1.33 

0.21 

1.15 

2.69 

4 

EXE 

27731 

10.0 

5.09 

29307 

1.67 

0.25 

1.47 

3.39 

5 

ARC 

51026 

18.0 

10.68 

53236 

3.00 

0.53 

2.66 

6.19 

6 

ARC 

150981 

43.0 

26.36 

157109 

7.16 

1.32 

7.86 

16.34 

VistaCOM-XMODEM  Upload 

1 

ARC 

8191 

3.0 

1.70 

8781 

0.50 

0.09 

0.44 

1.03 

2 

DOC 

21606 

8.0 

5.00 

22746 

1.33 

0.25 

1.14 

2.72 

3 

ARC 

21783 

7.5 

4.33 

23039 

1.25 

0.22 

1.15 

2.62 

4 

EXE 

27731 

10.0 

5.09 

29307 

1.67 

0.25 

1.47 

3.39 

5 

ARC 

51206 

17.5 

9.45 

53441 

2.92 

0.47 

2.67 

6.06 

6 

ARC 

150981 

51.0 

26.82 

157602 

8.50 

1.34 

7.88 

17.72 

COPXPC  Upload 

1 

ARC 

8191 

1.7 

1.42 

10719 

0.28 

0.07 

0.54 

0.89 

2 

DOC 

21606 

2.7 

3.05 

18009 

0.45 

0.15 

0.90 

1.50 

3 

ARC 

21783 

4.3 

2.62 

28700 

0.72 

0.13 

1.44 

2.29 

4 

EXE 

27731 

5.0 

2.93 

34670 

0.83 

0.15 

1.73 

2.71 

5 

ARC 

51206 

10.0 

5.29 

66974 

1.67 

0.26 

3.35 

5.28 

6 

ARC 

150981 

29.0 

14.41 

195793 

4.83 

0.72 

9.79 

15.34 

VistaHOST 

Upload 

1 

ARC 

8191 

1.9 

16.42 

13154 

0.32 

0.82 

0.66 

1.80 

2 

DOC 

21606 

3.0 

20.51 

17933 

0.50 

1.03 

0.90 

2.43 

3 

ARC 

21783 

5.0 

30.70 

32229 

0.83 

1.54 

1.61 

3.98 

4 

EXE 

27731 

5.0 

33.46 

33733 

0.83 

1.67 

1.69 

4.19 

5 

ARC 

51206 

10.0 

63.30 

75164 

1.67 

3.17 

3.76 

8.60 

6 

ARC 

150981 

30.0 

179.66 

221646 

5.00 

8.98 

11.08 

25.06 

VistaCOM  Vista  pcpack  Upload 

1 

ARC 

8191 

2.0 

12.60 

12776 

0.33 

0.63 

0.64 

1.60 

2 

DOC 

21606 

3.0 

16.61 

17629 

0.50 

0.83 

0.88 

2.21 

3 

ARC 

21783 

4.9 

18.37 

31212 

0.82 

0.92 

1.56 

3.30 

4 

EXE 

27731 

5.0 

19.36 

32669 

0.83 

0.97 

1.63 

3.43 

5 

P'Z 

51206 

11.0 

31.78 

72687 

1.83 

1.59 

3.63 

7.05 

6 

rtRC 

150981 

32.1 

77.09 

214114 

5.35 

3.85 

10.71 

19.91 

Chart  7: 

Upload  Benchmark  result.s 
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ABBREVIATIONS  AND  /  CRONYMS 


ASCII  American  Standard  Code  for  Information  Exchange 

CAPCES  Construction  Appioprianon,  Programming,  Control,  Execution  System 

CDC  Control  Data  Corp. 

CRC  cyclical  redundancy  check 

DBMS  database  management  system 

DC  Dugout  coordinator 

DOS  Disk  Operating  System 

EBCDIC  Extended  Binary-Coded  Decimal  Interchange  Code 

MCA  Military  Construction,  Army 

MYPLAN  Automated  Multi-Year  Plan  Application  Subsystem 

PAX  Programming,  Administration,  and  Execution 

PAXID  PAX  login  identification 

PC  personal  computer 

PCDID  PC  Dugout  login  identification 

RAM  random  access  memory 

REXX  Restructured  Extended  Executor 

SAA  Systems  Application  Architecture 

SQL/DS  structured  query  language/data  system 

TRU  transmission  unit 


USAGE  U.S.  Army  Coips  of  Engineers 

VM/CMS  Virtual  Machine/Conversational  Monitor  System 
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USACERL  DISTRffiUTION 


Chief  of  Engineers 
ATTN;  CEHEC-IM-LH  (2) 
ATTN:  CEHEC-IM-LP  (2) 
ATTN:  CECW-0 
ATTN;  CEMP 
ATTN:  CEMP-C 
ATTN:  CEMP-E(3) 

ATTN:  CEMP-M(3) 

ATTN:  CEMP-P(200) 

ATTN:  CERD-L 
ATTN:  DAEN-ZCE 
ATTN;  DAEN-ZCI(3) 

ATTN:  DAEN-ZCM 
ATTN:  DAEN-ZCZ 
ATTN:  DAEN-ZCP(3) 

CEHSC 

ATTN:  CEHSC-ZC  22060  (10) 
ATTN:  DETIII  79906 
ATTN;  CEHSC-F  22060 
ATTN:.  CEHSC-TT-F  22060 

US  Amy  Engr  Divisions 
ATTN:  Library  (14) 

Fort  Belvoir,  VA 
ATTN:  CECC-R  22060 


Defense  Technical  Info.  Center  22304 
ATTN:  DTIC-FAB  (2) 


253 

+1 

03/91 


